前言

今年 GSoC 專案公布時間為 8/23，共有 1223 通過審核能夠參與 GSoC，總共 1072 位學生成功通過。

今天的內文要為大家帶來 GNOME-Logs of GSoC 的報告解析，此份報告 是由 Liu Jiahui 所撰寫，原本希望得到「選上之後要做多少努力？」的觀察結果，不過在搜索整個參與的紀錄上發現結果可能不是那麼理想，不容易將努力的過程做總結，就先讓我們看一下這份報告的格式

1. 簡短的心得
2. 實際的貢獻（bugs/enhancements）
3. 貢獻是否有被採納？
4. 未來展望
5. 過程紀錄

2,3 點來說，可以知道 GNOME 針對專案的開發管理是建構在 gitlab ，而這位同學的 PR 目前都尚未被 merged ，而且筆者發現找不到這位同學是不是真的有通過第二、三次審核，雖然可以確定有通過第一次審核，不過這極有可能最後審核並沒有通過，可以看看部落格，因此讓我們深入 gitlab 來看看狀況

Gitlab 連結：Link

在 5-8 月這段時間

• 5 : No PR
• 6 : No PR
• 7 : Two PR
  • 7/17 still open (有相當多的對話內容)
  • 7/19 closed not merged
• 8 :
  • 8/5 closed not merged
  • 8/5 still open
  • 8/5 still open
  • 8/5 still open
  • 8/12 still open

8/5 四個 PR 發起的時間都在半夜的一小時內，也讓我對於先前的猜測也得到幾分證實，從軟體開發的角度一般都是越早有 commit 越早能有 review 與交流的機會，在八月快結束之前才同時發出 4 個 PR，並不是一個好現象。我試著從作者的部落格統整一下導致現狀可能的原因

1. GTK+ 的函式庫學習遇到瓶頸
2. GNOME-Logs 並沒有文件可以閱讀

這應該是最關鍵的兩個因素，尤其第二點，儘管有 Mentor 對於參與專案是很好的幫助，然而問別人以前先足功課是一種基本的功夫，因此我認為沒有充足的文件是一個硬傷，這代表深入專案的唯一方式是直接去讀原始碼，顯然作者是從「看程式碼＋開發新功能」著手，稍微瀏覽 gitlab 會發現 Mentor 會提出一些邏輯上的疑問，綜合下來，我想這位作者應該沒有掌握好原始碼，與最後集中發 PR 的現象，後期參與的活躍度並不夠，如果再深入去瞭解 ISSUE 也可以得知作者並沒有嘗試去解過 BUG，當然這很有可能是我的片面想法，不過單就我觀察到的資料，顯示的結果確實是不甚理想。

觀察結論與心得

前後約花了一小時瀏覽，但並沒有把部落格的文章深入瀏覽，在排版和字體的選擇上造成閱讀有相當的困難，真心建議可以使用 hackmd 來做技術筆記，最重要的是 hackmd 不會被牆！
就我們可以看到的資料並不足以斷言任何事情，有興趣可以看作者的 commit log，簡單總結我自己的心得

1. 挑選專案前，要選擇有文件的專案
2. 適當的評估所需技術，目前看來 GTK 並不好掌握
3. 開發 C 熟悉 GDB 的操作很重要，原因是在作者的部落格有提到進入 GTK Library 就無法透過 GDB 追蹤，不過後來被 Mentor 提示只有下適當的 GDB Symbol 即可。
4. Bugzilla 是一個常見的 bug 追蹤工具

這位作者跟 Mentor 的互動可能並不頻繁，而且初期參與熱度相當低，因為文章紀錄開始的時間為 7/21，可以說是相當的晚，也就是說並沒有善用和 Mentor 溝通的資源，這真的相當可惜，希望作者真的能夠照報告所寫會繼續參與開發，把五個 PR 成功合併。

預告

有鑒於這次的文章明顯就是在挑別人的缺點，但實際上筆者認為願意參與開源專案已是相當了不起的舉動，嘗試就是價值所在，因此明後天會更動系列方向，會針對 Bugzilla 做介紹，期望透過 Bugzilla 的介紹來瞭解開源專案 Bug 的生命週期，一探 bug 回報的奧妙。

回顧：預計每天花兩小時邊調查編寫文章，或許因為是編寫方式所以內容沒辦法太扎實（說好的深入呢QQ），也因為重讀過前兩天的文章，覺得文章架構相當鬆散，之後會盡力改進。